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DETAILED ACTION 



Information Disclosure Statement 



1 . The information disclosure statement (IDS) was filed on January.25, 2007. The submission is 
in compliance with the provisions of 37 C.F.R. 1.97. According, the examiner considered the 
IDS. 



Claim Rejections - 35 USC § 102 



2. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the 
basis for the rejections under this section made in this Office action: 
A person shall be entitled to a patent unless - 

(b) the invention was patented or described in a printed publication in this or a foreign country or in public use or on 
sale in this country, more than one year prior to the date of application for patent in the United States. 

(e) the invention was described in (1 ) an application for patent, published under section 1 22(b), by another filed 
in the United States before the invention by the applicant for patent or (2) a patent granted on an application for 
patent by another filed in the United States before the invention by the applicant for patent, except that an 
international application filed under the treaty defined in section 351(a) shall have the effects for purposes of this 
subsection of an application filed in the United States only if the international application designated the United 
States and was published under Article 2 1 (2) of such treaty in the English language. 



3. Claims 1-10, 17, and 19-26 are rejected under 35 U.S.C. 102(b) as being anticipated by Baker 
et al. (USP 6,266,700). 
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4. With regard to claims 1, 20, 21 and 22, Baker et al. discloses a method of testing equipment 
operatively connected to a medium having a protocol comprising: 

providing, a plurality of communication element types hierarchically representing 
different communication elements for the respective protocol [the user-defined hierarchical 
data structure is interpreted as the programmably configurable protocol descriptions 
which allow changes to existing protocols and supports new protocols to be added, col. 2, 
lines 53-59; any possible organization of fields for any possible protocol, col. 7, lines 17-20; 
defining the overall structure of the network protocol and reference other information 
(e.g., other protocols) relative to that network protocol, col. 7, lines 24-27]; 

providing an electronic instrument for operatively connecting to the equipment over the 
target medium and operating under control of a software program [the logic control module 
(interpreted as an electronic instrument in hardware, under control of software, connected 
to the target medium — Fig. 1, col. 2, lines 45-47; col. 4, lines 29-32; col. 6, lines 2-4; col. 6, 
lines 45-50) can perform a plurality of functions such as data manipulation, e.g., parsing, 
filtering, and analysis, col. 2, lines 50; logic control module 16 supports the 
configuration/reconfiguration of the programmably configurable protocol descriptions to 
handle different transmission hardware, protocols, and suites (in order to transmit or 
receive data over that different transmission hardware, protocol, or suite), col. 2, lines 59- 
67]; 
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instantiating, by the software program, at least one of the plurality of communication 
element types to create a transmit message instance; instantiating, by the software program, at 
least one of the plurality of communication element types to create an expect message instance; 
directing, by the software program, the electronic instrument to transmit a message to the 
equipment according to the transmit message instance and to receive a message from the 
equipment according to the expect message instance; and comparing the message received from 
the equipment with expected results to determine whether the expected results were obtained; 
[this is interpreted by the examiner as the test functions defined in Figs. 11-16; for example, 
in order to validate a value, a first message must be sent (transmit message), and then the 
received result (expect message) is compared to the desired result to determine if the value 
is valid or invalid (e.g., col. 16, line 53 to col. 17, line 10); thus, one can generate traffic with 
the ability to specify the methods for varying individual field values, col. 4, lines 44-49; See 
also specific instances of communications using the system: Fig. 11, running 
PARSEFRAME 100, running PARSEFIELDS 130/132, Fig. 12, running 
PARSEPROTOCOL 150, and Fig. 13A running PARSEFIELDS 200] 

wherein, each communication element type is a user-defined data structure that pertains 
to a particular layer of the protocol [user-defined is interpreted as the data structure which 
can be configured or reconfigured to handle numerous data manipulation functions (e.g., 
protocols), col. 2, lines 59-67]; and 
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wherein at least some communication element types relating to higher layers of the 
protocol include references to one or more communication element types relating to lower layers 
of the protocol [this is inherent in a system (software controlled) that parses frames and 
breaks them up into individual protocols and fields necessary for filtering, gathering 
statistics, generating network traffic, routing data, verifying field values (col. 2, lines 1-5) 
(generating multiple instances — claim 21); for example, this is interpreted as the system (1) 
receiving and determining the next protocol description structure to be used (table 4, 
lookup structure record, col. 8, lines 35-53) (processing multiple instances — claim 22) 
(reference to the message type — claim 20), then (2) finding the fields that describe the 
protocol header (table 1, protocol control record, col. 7, lines 24-46) (reference to the word 
type — claim 20), and then (3) computing the protocol checksum (table 6, checksum record, 
col. 9, lines 10-20 (reference to the field type — claim 20); this process is described in 
flowchart format: Fig. 11, PARSEFRAME 100, GET CURRENTPROTOCOL 102, then 
PARSEFIELDS 132, then Fig. 13 A, PARSEFIELDS 200, then Fig. 13B, VERIFY 
CHECKSUM 235]. 
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5. With regard to claim 25, Baker et al. discloses communicating over a target medium having a 
protocol [the logic control module can perform a plurality of functions such as data 
manipulation, e.g., parsing, filtering, and analysis, col. 2, lines 50; logic control module 16 
supports the configuration/reconfiguration of the programmably configurable protocol 
descriptions to handle different transmission hardware, protocols, and suites (in order to 
transmit or receive data over that different transmission hardware, protocol, or suite), col. 
2, lines 59-67], comprising: 

providing a plurality of communication element types for representing different 
communication elements of the protocol [the user-defined hierarchical data structure is 
interpreted as the programmably configurable protocol descriptions which allow changes 
to existing protocols and supports new protocols to be added, col. 2, lines 53-59; any 
possible organization of fields for any possible protocol, col. 7, lines 17-20; defining the 
overall structure of the network protocol and reference other information (e.g., other 
protocols) relative to that network protocol, col. 7, lines 24-27], each of the plurality of 
communication element types being a user-defined data structure that pertains to a particular 
layer of the protocol [user-defined is interpreted as the data structure which can be 
configured or reconfigured to handle numerous data manipulation functions (e.g., 
protocols), col. 2, lines 59-67]; 
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providing an electronic instrument for operatively connecting to the target medium for 
communicating over the target medium; providing a software program for controlling the 
electronic instrument [the logic control module (interpreted as an electronic instrument in 
hardware, under control of software, connected to the target medium — Fig. 1, col. 2, lines 
45-47; col. 4, lines 29-32; col. 6, lines 2-4; col. 6, lines 45-50) can perform a plurality of 
functions such as data manipulation, e.g., parsing, Altering, and analysis, col. 2, lines 50; 
logic control module 16 supports the configuration/reconfiguration of the programmably 
configurable protocol descriptions to handle different transmission hardware, protocols, 
and suites (in order to transmit or receive data over that different transmission hardware, 
protocol, or suite), col. 2, lines 59-67]; 
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arranging the plurality of communication element types hierarchically [the user-defined 
hierarchical data structure is interpreted as the programmably configurable protocol 
descriptions which allow changes to existing protocols and supports new protocols to be 
added, col. 2, lines 53-59; any possible organization of fields for any possible protocol, col. 
7, lines 17-20; defining the overall structure of the network protocol and reference other 
information (e.g., other protocols) relative to that network protocol, col. 7, lines 24-27], with 
at least one communication element type relating to a higher layer of the protocol including a 
reference to at least one communication element type relating to a lower layer of the protocol 
[this is inherent in a system (software controlled) that parses frames and breaks them up 
into individual protocols and fields necessary for filtering, gathering statistics, generating 
network traffic, routing data, verifying field values (col. 2, lines 1-5) (generating multiple 
instances); for example, this is interpreted as the system (1) receiving and determining the 
next protocol description structure to be used (table 4, lookup structure record, col. 8, lines 
35-53) (processing multiple instances) (reference to the message type), then (2) finding the 
fields that describe the protocol header (table 1, protocol control record, col. 7, lines 24-46) 
(reference to the word type), and then (3) computing the protocol checksum (table 6, 
checksum record, col. 9, lines 10-20 (reference to the field type); see also this process is 
described in flowchart format: Fig. 11, PARSEFRAME 100, GET CURRENTPROTOCOL 
102, then PARSEFIELDS 132, then Fig. 13A, PARSEFIELDS 200, then Fig. 13B, 
VERIFY CHECKSUM 235], 
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instantiating at least one of the plurality of communication element types by the software 
program to create at least one communication element instance; and operating the software 
program to control the electronic instrument to direct communications over the target medium, 
responsive to each communication element instance [this is interpreted by the examiner as the 
test functions defined in Figs. 11-16; for example, in order to validate a value, a first 
message must be sent (transmit message), and then the received result (expect message) is 
compared to the desired result to determine if the value is valid or invalid (e.g., col. 16, line 
53 to col. 17, line 10) ; thus, one can generate traffic with the ability to specify the methods 
for varying individual field values, col. 4, lines 44-49; specific instances of communications 
using the system: Fig. 11, running PARSEFRAME 100, running PARSEFIELDS 130/132, 
Fig. 12, running PARSEPROTOCOL 150, and Fig. 13A running PARSEFIELDS 200], 

6. With regard to claim 26, Bajcer et al. discloses communicating over a target medium having a 
protocol [the logic control module can perform a plurality of functions such as data 
manipulation, e.g., parsing, filtering, and analysis, col. 2, lines 50; logic control module 16 
supports the configuration/reconfiguration of the programmably configurable protocol 
descriptions to handle different transmission hardware, protocols, and suites (in order to 
transmit or receive data over that different transmission hardware, protocol, or suite), col. 
2, lines 59-67], comprising: 
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providing a plurality of message types and word types for representing communications 
using the protocol [this is inherent in a system (software controlled) that parses frames and 
breaks them up into individual protocols and fields necessary for filtering, gathering 
statistics, generating network traffic, routing data, verifying field values (col. 2, lines 1-5) 
(generating multiple instances); for example, this is interpreted as the system (1) receiving 
and determining the next protocol description structure to be used (table 4, lookup 
structure record, col. 8, lines 35-53) (processing multiple instances) (reference to the 
message type), then (2) finding the fields that describe the protocol header (table 1, protocol 
control record, col. 7, lines 24-46) (reference to the word type), and then (3) computing the 
protocol checksum (table 6, checksum record, col. 9, lines 10-20 (reference to the field 
type); see also this process is described in flowchart format: Fig. 11, PARSEFRAME 100, 
GET CURRENTPROTOCOL 102, then PARSEFIELDS 132, then Fig. 13A, 
PARSEFIELDS 200, then Fig. 13B, VERIFY CHECKSUM 235], each of the plurality of 
message types and word types being a user-definable data structure [user-defined is interpreted 
as the data structure which can be configured or reconfigured to handle numerous data 
manipulation functions (e.g., protocols), col. 2, lines 59-67]; 
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providing an electronic instrument for operatively connecting to the target medium for 
communicating over the target medium; providing a software program for controlling the 
electronic instrument [the logic control module (interpreted as an electronic instrument in 
hardware, under control of software, connected to the target medium — Fig. 1, col. 2, lines 
45-47; col. 4, lines 29-32; col. 6, lines 2-4; col. 6, lines 45-50) can perform a plurality of 
functions such as data manipulation, e.g., parsing, filtering, and analysis, col. 2, lines 50; 
logic control module 16 supports the configuration/reconfiguration of the programmably 
configurable protocol descriptions to handle different transmission hardware, protocols, 
and suites (in order to transmit or receive data over that different transmission hardware, 
protocol, or suite), col. 2, lines 59-67]; 

arranging the plurality of message types and word types hierarchically [the user-defined 
hierarchical data structure is interpreted as the programmably configurable protocol 
descriptions which allow changes to existing protocols and supports new protocols to be 
added, col. 2, lines 53-59; any possible organization of fields for any possible protocol, col. 
7, lines 17-20; defining the overall structure of the network protocol and reference other 
information (e.g., other protocols) relative to that network protocol, col. 7, lines 24-27], 
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with at least one message type including a reference to at least one word type [this is 
inherent in a system (software controlled) that parses frames and breaks them up into 
individual protocols and fields necessary for filtering, gathering statistics, generating 
network traffic, routing data, verifying field values (col. 2, lines 1-5) (generating multiple 
instances); for example, this is interpreted as the system (1) receiving and determining the 
next protocol description structure to be used (table 4, lookup structure record, col. 8, lines 
35-53) (processing multiple instances) (reference to the message type), then (2) finding the 
fields that describe the protocol header (table 1, protocol control record, col. 7, lines 24-46) 
(reference to the word type), and then (3) computing the protocol checksum (table 6, 
checksum record, col. 9, lines 10-20 (reference to the field type); see also this process is 
described in flowchart format: Fig. 11, PARSEFRAME 100, GET CURRENTPROTOCOL 
102, then PARSEFIELDS 132, then Fig. 13A, PARSEFIELDS 200, then Fig. 13B, 
VERIFY CHECKSUM 235]; 
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instantiating the at least one message type by a software program to create at least one 
message instance; and operating the software program to control the electronic instrument to 
direct communications over the target medium, responsive to the message instance [this is 
interpreted by the examiner as the test functions defined in Figs. 11-16; for example, in 
order to validate a value, a first message must be sent (transmit message), and then the 
received result (expect message) is compared to the desired result to determine if the value 
is valid or invalid (e.g., col. 16, line 53 to col. 17, line 10) ; thus, one can generate traffic 
with the ability to specify the methods for varying individual field values, col. 4, lines 44-49; 
specific instances of communications using the system: Fig. 11, running PARSEFRAME 
100, running PARSEFIELDS 130/132, Fig. 12, running PARSEPROTOCOL 150, and Fig. 
13A running PARSEFIELDS 200]. 

7. With regard to claim 2, Baker et al. discloses creating, by one of the software programs, 
instances of one or more communication element types for exchanging data on the respective 
target medium [can be configured and reconfigured to implement data manipulation 
functions and accommodate substantial network (bus) modification, col. 2, lines 59-67]. 

8. With regard to claim 3, Baker et al. discloses wherein the step of providing comprises 
defining one or more of the plurality of communication element types responsive to exchanges 
allowed by the protocol of the respective target medium [it is inherent that the communication 
element types would be defined; See also one or more programmable configurable program 
descriptions, col. 2, lines 50-52]. 
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9. With regard to claim 4, Baker et al. discloses creating, by one of the software programs, an 
instance of at least one of the plurality of communication element types [the system can 
perforin data manipulation, i.e., the logic control module can perform data manipulation, 
e.g., parsing, filtering, and analysis, col. 2, lines 50]; and 

processing each said instance for exchanging information on the respective target 
medium [logic module 16 processes the program description files and extracts field values 
or filtered values, col. 6, lines 15-19]. 

10. With regard to claim 5, Baker et al. discloses that at least one of the communication element 
types defines a structure for transmitting data over the target medium [logic control module 16 
supports the configuration/reconfiguration of the programmably configurable protocol 
descriptions to handle different transmission hardware, protocols, and suites (in order to 
transmit data over that different transmission hardware, protocol, or suite), col. 2, lines 59- 
67]. 

11. With regard to claim 6, Baker et al. discloses that at least one of the communication element 
types defines a structure for receiving data over the target medium [logic control module 16 
supports the configuration/reconfiguration of the programmably configurable protocol 
descriptions to handle different transmission hardware, protocols, and suites (in order to 
receive data over that different transmission hardware, protocol, or suite), col. 2, lines 59- 
67]. 
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12. With regard to claim 7, Baker et al. discloses that at least one communication element type 
is a message type that includes a portion for holding message data associated with instances of 
the respective message type [a data file 20 includes a protocol record organized into a 
plurality of predefined fields, col. 6, lines 64 to col. 7, lines 1; and can be organized to be 
used with any possible protocol, col. 7, lines 17-20]. 

13. With regard to claim 8, Baker et al. discloses that the message data has a fixed length [e.g., 
for example, a particular protocol header length may be fixed, col. 7, lines 3-7]. 

14. With regard to claim 9, Baker et al. discloses that the message data has a variable length [a 
data file 20 includes a protocol record organized into a plurality of predefined fields, col. 6, 
lines 64 to col. 7, lines 1; and can be organized to be used with any possible protocol, col. 7, 
lines 17-20]. 

15. With regard to claim 10, Baker et al. discloses that at least one of the communication 
element type has a fixed portion that is the same for all instances of the communication element 
type [e.g., for example, a particular protocol header length may be fixed, col. 7, lines 3-7]. 
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16. With regard to claims 17, 23, and 24, Baker et al. discloses [the logic control module can 
perform a plurality of functions such as data manipulation, e.g., parsing, filtering, and 
analysis, col. 2, lines 50; programmably configurable protocol descriptions allows changes 
to existing protocols and supports new protocols to be added, col. 2, lines 53-59; any 
possible organization of fields for any possible protocol, col. 7, lines 17-20; (inherently, this 
is a test program — claim 23)] a method further comprising, prior to the step of directing 
[creating a programmably configurable general protocol description, col. 5, lines 18-21; 
interpreted as prior to directing]: 

varying at least one characteristic of the transmit message instance by the software 
program [this is interpreted as determining (testing) dynamic/varying individual field values 
(e.g., using filtering control logic) and generating traffic with the ability to specify the 
methods for varying individual field values, col. 4, lines 44-49; thus, after entering the 
criteria to be tested/filtered, the control logic computes the validity, col. 18, lines 1-25; see 
also filtering criteria can be specified to any subset of bits in any field by allowing the 
criteria to be applied to every instance of that field which appears more than once in a 
frame, col. 18, lines 55-60 (testing varied characteristics of the multiple instances — claim 
24)]. 
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17. With regard to claim 19, Baker et al. discloses [the logic control module can perform a 
plurality of functions such as data manipulation, e.g., parsing, filtering, and analysis, col. 2, 
lines 50; the user-defined data structure is interpreted as the programmably configurable 
protocol descriptions which allow changes to existing protocols and supports new protocols 
to be added, col. 2, lines 53-59; any possible organization of fields for any possible protocol, 
col. 7, lines 17-20] a method further comprising: 

saving the plurality of communication element types in a computer readable format 
[written and saved in PDF format, col. 10, lines 51-58]. 



Claim Rejections - 35 USC § 103 



18. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all obviousness 
rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 



19. Claims 12-16, 18, 27, and 28 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Baker et al. as applied to claims 1-10, 17, and 19-26 above. 

20. With regard to claims 12-16 and 18, Baker et al. does not specifically disclose that each 
instance of the message type includes a portion for prescribing timing. However, Baker et al. 
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discloses being configured and reconfigured to implement data manipulation functions and 
accommodate substantial network (bus) modification, [col. 2, lines 59-67]. Baker et al. also 
discloses one or more programmable configurable program descriptions, [col. 2, lines 50-52]. 
Baker et al. discloses a system (logic control module), which can perform data manipulation, 
e.g., parsing, filtering, and analysis [col. 2, lines 50] wherein the logic module 16 processes the 
program description files and extracts field values or filtered values [col. 6, lines 15-19]. 
Additionally, Baker et al. discloses a logic control module 16 that supports the 
configuration/reconfiguration of the programmably configurable protocol descriptions to handle 
different transmission hardware, protocols, and suites (in order to transmit/receive data over that 
different transmission hardware, protocol, or suite) [col. 2, lines 59-67]. It is obvious to those of 
ordinary skill in the art that messages/words/packets in several protocols include timing 
characteristics (e.g., leading gaps [claims 13 and 14], trailing gaps [claim 16], and message 
timeouts [claim 15]), which must be specified for correct synchronization and proper extraction 
of headers and payloads. Moreover, Baker et al. discloses data file 20, which includes a protocol 
record organized into a plurality of predefined fields [col. 6, lines 64 to col. 7, lines 1], which 
can be organized to be used with any possible protocol [col. 7, lines 17-20]. Thus, it would have 
been obvious to one of ordinary skill in the art at the time of the invention to have included 
timing characteristics in the programmably configurable message types to handle substantial 
network (bus) modification as well as different transmission hardware, protocols, and suites 
because such timing characteristics are necessary for working with different types of technology 
and protocols which rely on those timing-based characteristics. 
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21. With regard to claims 27 and 28, Baker et al. discloses accessing an interface and/or using a 
software driver [col. 2, lines 59-67]. Baker et al. does not specifically disclose that the software 
program accesses a specific interface (API) or software driver (VXI). 28. However, Applicants 
have not disclosed that selecting a specific interface or a specific software driver solves any 
stated problem or is for any particular purpose other than an optimization of a known method of 
interfacing components and/or using a software driver. Accordingly, it would have been obvious 
to one of ordinary skill in the art at the time of the invention to modify the interface and/or 
software driver of Baker et al. because such modifications are considered a mere design choice 
consideration, which fails to patentably distinguish over the prior art of Baker et al. In addition, 
the changing of the interface and/or the software driver is interpreted as an optimum value for a 
known process. A discovery of an optimum value for a known process is obvious engineering. 
See In re Allen 105 USPQ 233 (CCPA 1955). 

Response to Arguments 

22. Applicant's arguments filed have been fully considered but they are not persuasive. 

23. With respect to claim 1, Applicants argue that Baker et al. does not "instantiate" the steps of 
the disclosed method [Applicant's Amendment dated January 25, 2007, page 3, paragraphs 
3-5]. The examiner respectfully disagrees. 
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24. As stated above, the rejection of claim 1 recites the test functions defined in Figs. 1 1-16. 
For example, in order to validate a value, a first message must be sent (transmit message), and 
then the received result (expect message) is compared to the desired result to determine if the 
value is valid or invalid [e.g., col. 16, line 53 to col. 17, line 10]. Thus, one can generate traffic 
with the ability to specify the methods for varying individual field values [col. 4, lines 44-49; 
specific instances of communications using the system: Fig. 11, running PARSEFRAME 
100, running PARSEFIELDS 130/132, Fig. 12, running PARSEPROTOCOL 150, and Fig. 
13A running PARSEFIELDS 200]. 

25. With respect to claim 1, Applicants argue that the messages transmitted and received are not 
compared [Applicant's Amendment dated January 25, 2007, page 3, paragraph 4 to page 4, 
paragraph 1]. The examiner respectfully disagrees. 

26. As stated above, the rejection of claim 1 recites the test functions defined in Figs. 1 1-16. 
For example, in order to validate a value, a first message must be sent (transmit message), and 
then the received result (expect message) is compared to the desired result to determine if the 
value is valid or invalid [e.g., col. 16, line 53 to col. 17, line 10]. Thus, one can generate traffic 
with the ability to specify the methods for varying individual field values [col. 4, lines 44-49; 
specific instances of communications using the system: Fig. 11, running PARSEFRAME 
100, running PARSEFIELDS 130/132, Fig. 12, running PARSEPROTOCOL 150, and Fig. 
13A running PARSEFIELDS 200]. 
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27. With respect to claim 25, Applicants argue that Baker et al. does not "instantiate" the steps 
of the disclosed method [Applicant's Amendment dated January 25, 2007, page 4, 
paragraphs 3-4]. The examiner respectfully disagrees. 

28. As stated above, the rejection of claim 25 recites the test functions defined in Figs. 11-16. 
For example, in order to validate a value, a first message must be sent (transmit message), and 
then the received result (expect message) is compared to the desired result to determine if the 
value is valid or invalid [e.g., col. 16, line 53 to col. 17, line 10]. Thus, one can generate traffic 
with the ability to specify the methods for varying individual field values [col. 4, lines 44-49; 
specific instances of communications using the system: Fig. 11, running PARSEFRAME 
100, running PARSEFIELDS 130/132, Fig. 12, running PARSEPROTOCOL 150, and Fig. 
13A running PARSEFIELDS 200]. 

29. With respect to claim 26, Applicants argue that Baker et al. fails to distinguish between 
types and instances [Applicant's Amendment dated January 25, 2007, page 4, paragraphs 6- 
7]. Applicants further argue that Baker et al. does not disclose a software program [Applicant's 
Amendment dated January 25, 2007, page 5, paragraph 1]. The examiner respectfully 
disagrees. 

30. First, in response to applicant's argument that the references fail to show certain features of 
applicant's invention, it is noted that the features upon which applicant relies (i.e., messages and 
words which are not "instances") are not recited in the rejected claims. Although the claims are 
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interpreted in light of the specification, limitations from the specification are not read into the 
claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). 

3 1 . Second, in response to applicant's argument that the method of communicating over a 
medium which involves message and word types (and, apparently, not message and word 
"instances"), a recitation of the intended use of the claimed invention must result in a structural 
difference between the claimed invention and the prior art in order to patentably distinguish the 
claimed invention from the prior art. If the prior art structure is capable of performing the 
intended use, then it meets the claim. 

32. Third, as stated above, the rejection of claim 26 recites that this is inherent in a system 
(software controlled) that parses frames and breaks them up into individual protocols and 
fields necessary for filtering, gathering statistics, generating network traffic, routing data, 
verifying field values [col. 2, lines 1-5; i.e., generating multiple instances]. For example, a 
system which (1) receives and determines the next protocol description structure to be used 
[table 4, lookup structure record, col. 8, lines 35-53; i.e., processing multiple instances; 
reference to the message type]. Then (2) finds the fields that describe the protocol header 
[table 1, protocol control record, col. 7, lines 24-46; reference to the word type]. Then (3) 
computes the protocol checksum [table 6, checksum record, col. 9, lines 10-20; reference to 
the field type; this process is described in flowchart format: Fig. 11, PARSEFRAME 100, 
GET CURRENTPROTOCOL 102, then PARSEFIELDS 132, then Fig. 13A, 
PARSEFIELDS 200, then Fig. 13B, VERIFY CHECKSUM 235]. 
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Conclusion 

33. Applicant's amendment necessitated the new grounds of rejection presented in this Office 
action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is 
reminded of the extension of time policy as set forth in 37 CFR 1.136(a). 

34. A shortened statutory period for reply to this final action is set to expire THREE MONTHS 
from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of 
the mailing date of this final action and the advisory action is not mailed until after the end of the 
THREE-MONTH shortened statutory period, then the shortened statutory period will expire on 
the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be 
calculated from the mailing date of the advisory action. In no event, however, will the statutory 
period for reply expire later than SIX MONTHS from the date of this final action. 

35. Any inquiry concerning this communication or earlier communications from the examiner 
should be directed to Mark A. Mais whose telephone number is 572-272-3 138. The examiner 
can normally be reached on M-Th 5am-4pm. 

36. If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, 
Wing Chan can be reached on 571-272-7493. The fax phone number for the organization where 
this application or proceeding is assigned is 571-273-8300. 
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37. Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would 
like assistance from a USPTO Customer Service Representative or access to the automated 
information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 

May 21, 2007 




WELLINGTON CHIN 
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